Method and system for ride shares involving hierarchical driver referrals

ABSTRACT

Systems and methods according to which a mobile application is running on a driver&#39;s mobile device for authenticating ride share drivers. When a driver initially registers with a rideshare service, the driver is prompted to provide biometric information via a mobile app running on the driver&#39;s mobile device. The biometric information is then stored in a database with a ride share management server in a file associated with the driver&#39;s account. Subsequently, when the driver expresses an offer to provide a ride share trip, the server performs an authentication check based on the pre-stored biometric information. Furthermore, the system discloses herein facilitates increased rideshare revenue generation by creating referral chains for a driver when a previously-registered driver, or an affiliate of the rideshare service refers a proposed new driver to the rideshare service and the proposed new driver then registers with the rideshare service.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/938,129 filed Nov. 11, 2015 and incorporated by reference herein inits entirety, which claims priority to, and incorporates by reference,U.S. provisional patent application No. 62/124,196 filed Dec. 11, 2014.

TECHNICAL FIELD

The present disclosure relates generally to vehicle rideshares. Morespecifically, embodiments of the present disclosure relate to systemsand methods for facilitating vehicle rideshare involving a computerizedhierarchical driver referral system and a biometric scan-basedauthentication of a rideshare driver's identity.

BACKGROUND AND SUMMARY

Historically, passengers who do not wish to drive or use publictransportation use taxi cabs to travel from one place to another.Recently, rideshare systems have become available as another source oftransportation. Typically passengers request a ride from a driver byusing an app on the passenger's mobile device. The mobile appcommunicates with a server managed by a rideshare system or service andprovides information about the passenger's location. In turn, the serversends out a request to drivers in the general vicinity of thepassenger's location, and also informs the passenger of average pickuptimes for drivers in the vicinity. Once the passenger selects a driverand an associated vehicle, the passenger is provided with the driver'sinformation such as a name, a phone number, and an expected time ofarrival. After the driver has provided the ride to the passenger, thepassenger's credit card or debit card (typically stored in a databasecoupled to the rideshare server) is charged.

One concern about known rideshare systems is that they do not provideadequate security measures to protect passengers. For example, anunauthorized person can impersonate a ride share driver and provide aride to an unsuspecting passenger. Another concern is that knownrideshare systems do not utilize technology effectively to adequatelyincentivize new drivers to become part of the riding sharing service.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates an example system for facilitating ridesharesutilizing a ride share management server.

FIG. 2 illustrates example registration screens of a mobile deviceinterface for registering drivers with an embodiment of the ride sharemanagement server, according to an embodiment of the present invention.

FIG. 3 illustrates a mobile device interface for receiving biometricinformation from drivers, according to an embodiment of the presentinvention.

FIG. 4 illustrates a schematic of discrete pairwise operations involvinga driver's mobile app, a passenger's mobile app, a ride share managementserver, a navigation API, and a geocoding server associated with startof a trip, according to an embodiment of the present invention.

FIG. 5 illustrates a schematic of discrete pairwise operations involvinga driver's mobile app, a passenger's mobile app, a ride share managementserver, a passenger portal, and a geocoding server associated with endof a trip, according to an embodiment of the present invention.

FIG. 6 illustrates a schematic of operations associated with a driver'smobile app according to an embodiment of the present invention.

FIG. 7 illustrates a flow diagram showing method steps by a mobile appfor registering a driver according to an embodiment of the presentinvention.

FIG. 8 illustrates a flow diagram showing method steps by a mobile apprunning on a driver's mobile device in connection with a driver offeringto provide a rideshare trip according to an embodiment of the presentinvention.

FIG. 9 illustrates a flow diagram showing method steps by a mobile apprunning on a passenger's mobile device in connection with a passengeravailing a rideshare trip, according to an embodiment of the presentinvention.

FIG. 10 illustrates a flow diagram showing method steps by a rideshareserver identifying referral chains according to an embodiment of thepresent invention.

FIG. 11 illustrates several example mobile device interface screens of adriver's mobile app according to an embodiment of the present invention.

FIGS. 12-14 illustrate example interfaces showing earnings accumulatedvia a driver's referral chain according to an embodiment of the presentinvention.

FIG. 15 illustrates an example interface displaying a driver's earningshistory according to an embodiment of the present invention.

FIG. 16 illustrates an example interface showing a passenger's triphistory according to an embodiment of the present invention.

FIG. 17 illustrates an example interface showing a passenger's pickuplocation with respect to a rideshare driver's location displayed on amap according to an embodiment of the present invention.

FIGS. 18-19 illustrate example interfaces linked to a driver databaseaccording to an embodiment of the present invention.

FIG. 20 illustrates an example interface linked to a passenger databaseaccording to an embodiment of the present invention.

FIGS. 21-22 illustrate example interfaces for a network marketer toaccess the rideshare server via a network marketer portal, according toan embodiment of the present invention.

DETAILED DESCRIPTION

In one aspect, the inventive disclosure provided herein generallyrelates to systems and methods for authenticating ride share driversusing a biometric sensor. When a driver initially registers with therideshare service, the driver is prompted to provide biometricinformation via a mobile app running on the driver's mobile device. Thebiometric information is then stored in a database with a ride sharemanagement server in a file associated with the driver's account.Subsequently, when the driver expresses an offer to provide a ride sharetrip, the server performs an authentication check based on thepre-stored biometric information. Particularly, the driver provides hisor her biometric information to the ride share management server via amobile application on the driver's mobile device. This information isthen checked against the stored biometric information in the networkeddatabase to authenticate the identity of the driver. If authenticated,the driver receives pick-up information, including the passenger'spickup location and desired destination. In the meantime, the ride sharemanagement server notifies the passenger about the details of therideshare driver and the rideshare vehicle via the mobile app on thepassenger's mobile device. Once the driver arrives at the pickuplocation of the passenger and picks up the passenger, the ride sharetrip starts.

In some embodiments, the biometric information is stored insidenon-volatile memory in or coupled to the driver's mobile device.Subsequently, when offering a rideshare trip, an identity of a driverwho offers the rideshare trip is checked (by the mobile app running onthe driver's mobile device) against the stored biometric information toauthenticate the identity of the driver. However, the comparison of thebiometric information received versus the pre-stored biometricinformation is performed by the rideshare server. Thus, in suchimplementations, the stored biometric information is transmitted fromthe driver's mobile device to the rideshare server, prior to thecomparison.

Drivers' mobile devices are configured to enable drivers to providebiometric information via a sensor coupled to or otherwise configuredwithin a driver's respective mobile device. A biometric scan caninclude, for example, fingerprint, voice, iris recognition, or acombination thereof. In some embodiments, a driver's mobile device, apassenger's mobile device, or both can be configured to enable receiptof biometric scans, process such scans to determine if the scan wassuccessful, and transmit such scans to a ride share management server.The ride share management server compares the biometric scan of a driveroffering to provide a ride share trip against a stored biometric scan toauthenticate the identity of the driver. The biometric scan of a drivercan be stored along with other types of driver information such as aname, license information, social security number, car information,picture of driver and the car, ride history of the driver accumulatedover time, criminal background check, driver ratings by passenger, etc.In some aspects, a data structure associated with a driver enablesstorage and manipulation of different types and formats (e.g.,alphabetical, numeric, alphanumeric, etc.) of data about a driver. Insome embodiments, a passenger can access some of the data relating to adriver. For example, a passenger can access such information at thestart of a trip until the trip is over.

In another aspect, the inventive disclosure relates to a computerizedmethod and system for facilitating increased rideshare revenuegeneration by creating referral chains for a driver when apreviously-registered driver (e.g., “Driver A”) refers a proposed newdriver (e.g., “Driver B”) to the rideshare service and the proposed newdriver then registers with the rideshare service. In this scenario, thereferral chain can provide additional revenue for thepreviously-registered driver by accumulating a percentage of earningsfrom the proposed new driver. This referral chain can span a number oflevels (e.g., five levels of referrals). In some embodiments, a driverwho has been referred by a registered driver is prevented from beingreferred by another registered driver. In some aspects, a registereddriver who refers a new driver provides a referral ID to that is used bythe proposed new driver when signing up with the rideshare service. Insome other aspects, a registered driver notifies the ride sharemanagement server that he or she has provided a referral ID to the newdriver. Accordingly, when the new driver registers with the rideshareservice, the new driver may be required to provide the referral IDprovided by the registered driver. Such a methodology can preventoccurrences where a new driver has been referred by a registered driverbut does not provide the referral ID provided by the registered driverin an attempt to avoid sharing his or her earnings with the referringdriver.

When a driver who has been referred by another driver signs up with theridesharing service, a mobile app running on a referring (registered)driver's mobile device is updated to show the referral chain. That is,data relating to the new driver is transferred to the registereddriver's mobile app. Thus, embodiments of the present disclosure enablepush notifications to be received by an app running on a driver's mobiledevice. The app running on a driver's mobile device can be configured toreceive notifications on-the-fly from a ride share management server.The referral chain of the registered driver can be stored on theregistered driver's mobile app, and additionally in a databaseassociated with the rideshare service.

When a driver completes a ride, an electronic payment is processed suchthat requisite funds amounting to the cost of a ride are transferredfrom a passenger's financial institution to the rideshare service. Forexample, a driver who provided the ride can receive 85% of the cost of aride, and the remaining 15% is retained by the rideshare service. Insome aspects, details relating to a passenger's financial institutionare stored in a passenger database associated with the rideshare servicewhen the passenger registers with the rideshare service. After receivingthe funds, the rideshare service retains a percentage from each driverin a referral chain. In addition, the registered driver who has referredthe subject driver also earns a percentage of the earnings. For example,in a referral chain in which driver 1 refers driver 2, and driver 2offers a ride to a passenger, driver 2 earns 85% of the cost of theride. The remaining 15% is divided between the rideshare service anddriver 1. Thus, in some scenarios, the driver who provided the rideearns 85% of the cost of a ride. The remaining 15% is divided among therideshare service and the other driver(s) in the referral chain,according to certain percentages. In another example, in which driver 1refers driver 2, driver 2 refers driver 3, driver 3 refers driver 4, andso on, the rideshare service retains 15% of driver 1's earnings, 11% ofdriver 2's earnings, 8.5% of driver 3's earnings, 7% of driver 4'searnings, and so on. Similarly, driver 1 earns 4% of driver 2'searnings, 2.5% of driver 3's earnings, 1.5% of driver 4's earnings, andso on. (These percentages can vary, and are examples for discussionpurposes only.) In some embodiments, payments from a passenger'sfinancial institution can be processed via a third payment processoracting as an intermediary between the passenger's financial institutionand the rideshare service.

In some embodiments, the inventive disclosure relates to a computerizedmethod and system for creating referral chains when a network marketerrefers a proposed new driver to the rideshare service and the proposednew driver then registers with the rideshare service. A networkmarketer, as used herein, is an individual or an entity that is not aregistered driver of the rideshare service. A referral chain started bya network marketer can provide a revenue generation stream for thenetwork marketer by accumulating a percentage of earnings from theproposed new driver. Referral chains by network marketers can havefeatures and functionalities that are similar to referral chains bydrivers. For example, the referral chain can span a number of levels(e.g., five levels of referrals). A network marketer who refers a newdriver provides a referral ID that is used by the proposed new driverwhen signing up with the rideshare service. In some other aspects, anetwork marketer notifies the rideshare management server that he or shehas provided a referral ID to the new driver. Accordingly, when the newdriver registers with the rideshare service, the new driver may berequired to provide the referral ID provided by the network marketer. Insome embodiments, a network marketer can access the rideshare servicevia a network marketer portal for providing information to the rideshareserver, checking earnings/invoices as a result of earnings fromrideshare drivers that are part of the network marketer's referralchain, etc. Percentages of earnings from a network marketer-referreddriver can, in some embodiments, be similar or different thandriver-referred scenarios discussed above.

Various aspects and examples of the embodiments will now be described.The following description provides specific details for a thoroughunderstanding and enabling description of these examples. One skilled inthe art will understand, however, that the embodiments may be practicedwithout many of these details. Additionally, some well-known structuresor functions may not be shown or described in detail, so as to avoidunnecessarily obscuring the relevant description.

FIG. 1 illustrates an example system where a rideshare management server130 facilitates providing ride share trips to passengers 114 in vehiclesdriven by ride share drivers 112. Passengers 114 and ride share drivers112 own, operate, or otherwise have access to mobile devices 122.Determining a trip can, in some embodiments, involve queries to ageocoding server 116. A payment processor 120 is used to disbursepayments to ride share drivers based on the cost of a rideshare trip. Apassenger can pay the cost of a rideshare trip using a debit card or acredit card associated with a financial institution server 118.

It will be understood that the ride share management server 130, whichcan be referred to as the “rideshare server,” can be a single server ora plurality of interconnected servers that are configured to exchangeinformation. Further, such a server or a plurality of servers can becloud-based or can be physical servers.

In the exemplary scenario shown in FIG. 1, a passenger 114 is waiting ata geographical location for a rideshare driver 112 to arrive and pick upthe passenger 114. Passenger 114 requests rideshare server 130 for aride share trip by launching a mobile application on the passenger'smobile device 122. The request typically includes information relatingto the passenger's geographical location (e.g., latitude longitude)obtained via a location mechanism (e.g., a GPS sensor) on thepassenger's mobile device 122 and an intended destination provided bythe passenger 114. In some instances, a passenger 114 can request anestimated cost of the rideshare trip from the rideshare server 130.

In some embodiments, a mobile application associated with the rideshareservice can function dually as a mobile application for a passenger 114as well as that for a driver 112. Thus, depending on whether anindividual is logging in as a passenger 114 or as a driver 112, the samemobile application can be used for both purposes. For purposes ofdiscussion and illustration, the terms “a mobile application running ona driver's mobile device,” “a driver's mobile app,” and “a driver app”would be considered analogous. Similarly, the terms “a mobileapplication running on a passenger's mobile device,” “a passenger'smobile app,” and “a passenger app” would be considered analogous.

A driver 112 in the vicinity offering to provide a rideshare triplaunches a mobile application on the driver's mobile device 123. In someembodiments, the mobile application requests the driver 112 to providehis or her biometric information to the rideshare server 130 every timea driver launches the mobile application for offering a rideshare trip.A driver's mobile device 123 can be configured to enable a driver 112 toprovide biometric information via a sensor coupled to or otherwiseconfigured within a driver's respective mobile device 123. A biometricscan can include, for example, fingerprint, voice, or iris recognition,or a combination thereof. In some embodiments, the driver's mobiledevice 123 can be configured to enable receipt of biometric scans,process such scans to determine if the scan was successful, and transmitsuch scans to a rideshare server 130. The rideshare server 130 checksthe biometric information provided by the driver offering to provide theride share trip against the stored biometric information in a networkeddatabase to authenticate the identity of the driver 112.

If authenticated, the driver 112 is provided with the destination of thepassenger 114 and a pickup location of the passenger 114. The passenger114 is notified of details of the rideshare driver 112 and the ridesharevehicle, via the mobile app on the passenger's mobile device 122, by therideshare server 130. For example, the ride share server 130 can providethe passenger 114 with a name and contact information (e.g., phonenumber, email, etc.) of the driver 112, a photograph of the driver 112,a make, year, model and photograph of the vehicle that the driver 112 isdriving.

In some instances, the rideshare server 130 provides an estimate of therideshare trip to the passenger 114. The wait time for the passenger 114waiting for the rideshare driver 112 to arrive at the passenger's pickuplocation is typically a couple of minutes or less. The driver 112arrives at the pickup location of the passenger 114, picks up thepassenger 114 and the ride share trip starts. In some embodiments, atrip starts when a driver clicks on a button to start a trip using themobile application running on the driver's mobile device 123. In somescenarios, more than one driver can respond to rideshare server 130 withan offer to provide a rideshare trip to passenger 114. In such ascenario, the ride share server 130 can choose a driver 112 randomly, orcan choose a driver 112 who is closest to the passenger 114.

In some embodiments, the rideshare server 130 communicates with ageocoding server 116 to provide real time navigation directions to thedriver 112, on the way to the passenger's destination. For example, arideshare server 130 can query (e.g., via an API call) the geocodingserver 130 with the intended destination provided by the passenger 114to obtain the real time navigation directions. The geocoding serverprovides the navigation directions (e.g., route information of therideshare trip on a map) to the rideshare server 130 which is conveyedin real time to a mobile application running on the driver's mobiledevice 123, and optionally to the passenger's mobile device 122. Themobile application running on the driver's mobile device 123 can alsocompute information relating to a net distance traveled from thepassenger's pickup location, a time of travel, etc. Such information canbe used to calculate a total cost of the rideshare trip. In someembodiments, geocoding server 116 performs some or all of thesecomputations, and provides the same to the mobile application running onthe driver's mobile device 123.

In some embodiments, a passenger 114 goes through a one-timeregistration process (usually at any time before the first ridesharetrip of the passenger 114) in which the passenger 114 provides his orher details, e.g., name, email, phone number, credit/debit cardinformation, name of a financial institution associated with thecredit/debit card, etc. to the rideshare server 130. In someembodiments, information relating to a passenger 114 is stored in anetworked database (e.g., as a data structure) and can be viewed and/oredited by the passenger 114 via a passenger portal module 134 accessibleby any electronic device connected to the Internet, including the mobileapplication running on the passenger's mobile device 122. In someembodiments, the mobile application running on the passenger's mobiledevice 122 stores a copy of the passenger's personal and financialinformation.

When the passenger 112 arrives at the intended destination, therideshare trip ends. Information relating to the rideshare trip, e.g.,duration of trip, distance traveled, route taken, etc. is also obtainedby the mobile application running on the driver's mobile device 123. Insome embodiments, the mobile application running on the driver's mobiledevice 123 calculates the total cost of the rideshare trip, e.g., on thebasis of a monetary value per unit time of rideshare travel. In someembodiments, such information is communicated to the rideshare server130. The rideshare server 130 typically provides that information(partially or entirely) to the mobile application running on thepassenger's mobile device 123. In some embodiments, the mobileapplication on the passenger's mobile device 123 also provides an optionto pay a tip to the rideshare driver 114. After reviewing the details ofthe trip, a passenger 112 can approve of the payment of the cost of thetrip via the mobile application running on the passenger's mobile device123. In some embodiments, the mobile application running on the driver'smobile device 123 goes offline, for example, breaks off communicationwith the rideshare server 130 when a trip ends. Thus, in suchembodiments, a driver who wishes to offer to provide a subsequentrideshare trip re-launches the mobile application, and re-scans his orher biometric information for authentication.

Upon receiving the passenger's approval, in some embodiments, therideshare server 130 communicates with a payment processor 120(typically via an API call). Payment processor 120 is a third partyfinancial services provider that allows both private individuals andbusinesses to accept payments over the Internet. For example, thepayment processor 120 can initiate payment transactions associated withpayment of the cost of the trip from the passenger's financialinstitution server 118.

In some embodiments, a second driver 112 shares his or her earnings witha first driver 112 in a scenario in which the first driver 112 hasreferred the second driver 112 to sign up with the rideshare service asa driver. Thus, embodiments of the disclosed system facilitate thecreation of referral chains which can provide residual income todrivers, after funds amounting to the cost of a rideshare trip isreceived from a passenger's financial institution.

In some optional embodiments as shown in FIG. 1, the rideshare server130 includes a backend module 132, a passenger portal module 134, adriver portal module 136, and a network marketer portal module 138.Typically, the passenger portal module 134 and the driver portal module136 are accessible by electronic devices such as mobile devices,laptops, desktops, tablet PCs, etc. connected to the Internet as well asmobile devices including but not limited to the driver's mobile device122, passenger's mobile device 123, the geocoding server 116, and thepayment processor 120. In some embodiments, the network marketer portalmodule 138 is accessible via the web only, and not via mobileapplications on mobile devices. In some other embodiments, the networkmarketer portal module 138 can be accessible via mobile applicationsrunning on mobile devices. The network marketer portal module 136 can,for example, be accessed by a network marketer module to provideinformation about a proposed new driver to the rideshare server 130, oreven directly refer a proposed new driver via the network marketerportal module 136. A network marketer can also receive referral IDsgenerated by the rideshare server 130 to be shared or sent (e.g., via asocial media network or in an email communication) to the proposed newdriver.

Thus, embodiments of the present disclosure enable both drivers 112 andpassengers 114 to view their profile and affiliated information using apassenger portal module 134 and a driver portal module 136 hosted by therideshare service. For example, both passengers and drivers canrespectively view their profile information, their trip history, theirpayment history, their invoices, etc. The back end module 132 istypically involved in calculation of payments, maintenance andmanipulation of passenger and driver data stored in networked databases,etc. In some embodiments, functionalities of the back end module 132can, in whole or in part, be performed by one or more of the portalmodules disclosed herein, and vice versa. Furthermore, in someembodiments, the rideshare server 130 can include a single module forperforming various functionalities.

Examples of mobile devices 122 and 123 include but are not limited totablets, mobile smart phones, personal digital assistants, wearableconsumer devices, etc. These mobile devices can run, for example, thepopularly-known ANDROID™′ IPHONE™, and WINDOWSPHONE™ platforms. It willbe understood that there is no limitation imposed on the number ofmobile devices, mobile device types, brands, vendors and manufacturersthat may be used with embodiments of the present disclosure.

Electronic data communications between elements shown in FIG. 1 can beachieved via one or more networks 110, such as, but not limited to, aLocal Area Network (LAN), Wireless Local Area Network (WLAN), Personalarea network (PAN), or wireless wide area network (WWAN), enabled withtechnologies such as Global System for Mobile Communications (GSM),Personal Communications Service (PCS), Bluetooth, Wi-Fi, Fixed WirelessData, 2G, 2.5G, 3G, 3G LTE, LTE Advanced, 4G, general packet radioservice (GPRS), messaging protocols such as, TCP/IP, SMS, MMS, instantmessaging, or any other wireless data networks or messaging protocols.Although not shown in FIG. 1, it can be further understood that suchcommunications may include one or more secure networks, gateways, orfirewalls that provide information security from unwarranted intrusionsand cyber attacks. In some embodiments, the landmark server 130 includesfunctionality to allow it to communicate, for example, by usingapplication programming interfaces (APIs), with various elements shownin FIG. 1.

FIG. 2 illustrates exemplary registration screens of a mobile deviceinterface for registering drivers with an embodiment of the rideshareserver, according to an embodiment of the present invention. Forexample, upon launching a mobile application associated with therideshare server 130 for the first time, a mobile application running ona driver's mobile device displays screen 210. Screen 210 shows variousexemplary driver-related information fields such as a name field, a dateof birth field, a gender field, a country field, a city field, anaddress field, and an email id field. For example, in some scenarios,the date of birth information can be used to determine an age of thedriver, such that drivers under the age of twenty-one, for instance, arenot allowed to sign up as drivers with the rideshare service. In suchscenarios, the mobile application displays a message “You are NotEligible to Drive.” Upon filling up the fields displayed on this screen,a driver clicks on a “Next” button to land at screen 220. If the date ofbirth provided by the driver is a current date, then the mobileapplication displays a message on the screen of the mobile device. Ifthe email id provided by the registering driver is in a wrong format,then the mobile application displays a message “Incorrect Email IDformat.” Screen 210 also shows an option for a driver to upload his orher photograph via the mobile application running on the driver's mobiledevice, e.g., either by taking a photograph via the camera on the mobiledevice or uploading a pre-stored photograph saved in a memory of themobile device. Screen 220 shows various exemplary fillable informationfields of a vehicle that can be used to provide a rideshare trip.Example of such fields shown in screen 220 are a vehicle number, a typeof vehicle, a license number of the driver, a registration number of thevehicle, an insurance policy number of the vehicle, a license expirationdate of the driver, a registration expiration date of the driver, aninsurance expiration date, etc. Screen 220 also shows an option foruploading a photograph of the vehicle. Upon filling up the fieldsdisplayed on this screen, a driver clicks on a “Next” button to land atscreen 230. Screen 230 shows a driver's bank-related information such asa bank name and a bank account number, for receiving earnings associatedwith a ride share trip. Screen 230 also shows details to be filled by adriver for payments involving a (third party) payment processor. In someaspects, a driver can enter the information on the displayedregistration screens 210, 220, and 230 and edit them if he or shedesires. Such information is finally communicated from the mobileapplication running on the driver's mobile device to the rideshareserver 130, after the driver clicks a “Submit” button. In someembodiments, if the driver skips filling up any field, then the mobileapplication displays a message “All Fields are Mandatory.” In someembodiments, information provided by a driver during a registrationprocess is communicated to the rideshare server 130 for storage in adatabase. In some embodiments, some or all of the information providedby a driver during a registration process can be saved on the driver'smobile device. In some embodiments, the rideshare server 130 keeps trackof various dates, e.g., dates of registration renewal, license renewal,insurance renewal etc. Accordingly, in such embodiments, the rideshareserver 130 sends an email to the driver in advance of the renewaldate(s) so that the driver can take necessary actions.

FIG. 3 illustrates a mobile device interface for receiving biometricinformation from drivers, according to an embodiment of the presentinvention. Screen 310, used for entering a driver's bank information forreceiving earnings associated with a rideshare trip is similar to screen230 shown in FIG. 2. Screen 320 shows a predetermined scanning area onthe screen of a driver's mobile device. The predetermined scanning areais a region inside which a driver can place his or her finger (rightthumb, for example) in connection with providing the driver's biometricinformation. Drivers' mobile devices are configured to enable drivers toprovide biometric information via a sensor coupled to or otherwiseconfigured within a driver's respective mobile device. Screen 330 showsa message displayed on the screen of a driver's mobile indicating thatthe mobile application is processing an image associated with thebiometric scan of a driver's finger. If the mobile application on thedriver's mobile device determines that the biometric scan wassuccessful, screen 340 shows an option to save the biometric scan. Insome optional embodiments, as shown in screen 340, the mobileapplication on the driver's mobile device can provide an option tore-take another biometric scan. In some embodiments, informationprovided by a driver during a registration process is communicated tothe rideshare server 130 for storage in a database. In some embodiments,some or all of the information provided by a driver during aregistration process can be saved on the driver's mobile device.

FIG. 3 also displays a portion of a computer-implemented interface 350that is linked to a database which stores the driver's biometricinformation. Interface 350 displays, for example, a driver (“provider”)with an id “1,” a name “Josh” having a biometric scan 360 linked to hisemployee account. Embodiments of the disclosed system utilize thebiometric scan to authenticate the identity of a driver any time thedriver launches the mobile application. Interface 350 also displaysadditional driver-related details such as a phone number, a linkedphotograph of a driver, a total number of trips that the driver hasoffered, and an approval status corresponding to whether the driver wasapproved by the system based on his background and driving history.Interface 350 also provides a drop-down menu displaying selectableactions that can be taken by an individual viewing this interface.Although FIG. 3 displays fingerprint recognition as a biometric,embodiments of the disclosed system can also different types ofbiometric scan, such as, fingerprint, voice, or iris recognition, or acombination thereof.

FIG. 4 illustrates a schematic indicating operations involving adriver's mobile app 402, a passenger's mobile app 408, a rideshareserver 130, a navigation API 440, and a geocoding server 116 associatedwith start of a trip, according to an embodiment of the presentinvention. It is noted that the operations shown in FIG. 4 are notnecessarily performed in a sequence or in an order of any sort.According to some embodiments, a driver who offers to provide arideshare trip provides a biometric scan via the driver's mobile app. Insome embodiments, the biometric scan is compared against a pre-storedscan of the driver stored in the driver's mobile phone. For example, thepre-stored scan can be a scan provided by the driver at the time ofregistration. The process of comparing the biometric scan received froma driver with the pre-stored scan can, in some embodiments, be performedby the driver's mobile app 402. In some other embodiments, the driver'smobile app transmits the biometric scan to rideshare server 130 forcomparison against a pre-stored scan.

If the driver is authenticated (412), a driver receives the passenger'spickup location and the passenger's intended destination from geocodingserver 116 (or, in some embodiments, from the rideshare server 130)displayed on a map. In some embodiments, the driver's mobile app 402integrates the received information updating the map displayed on thedriver's mobile device with, for example, a real-time indication of thedriver's location and the passenger's pickup location. For example, insome embodiments, the driver app 402 can display a marker on a mapcorresponding to the driver's location and the passenger's pickuplocation. Further, as the driver travels towards the passenger's pickuplocation, the driver marker is shown to accordingly move on the map. Insome embodiments, the driver app 402 sends (416) real-time informationrelating to the updated map, e.g., displaying the markers to thegeocoding server 116. In some embodiments, the geocoding servertransfers the information received from the driver app 402 to therideshare server 130 in real time. In some other embodiments, the driverapp 402 sends real-time information relating to the updated map, e.g.,displaying the markers directly to the rideshare server 130. It will beunderstood and appreciated that functionalities wherein the rideshareserver 130 obtains a driver's real-time location allow the rideshareserver 130 to track the driver's location. Upon detecting that thedriver has reached the location, the driver receives (at step 424) anotification of a start of a trip from the rideshare server 130. In someembodiments, a driver first informs (via the driver's mobile app 402)the rideshare server 130 that he or she has arrived at the passenger'spickup location before receiving a notification of a start of the tripfrom the rideshare server 130. In some scenarios, a driver clicks on aStart Trip button via driver app 402 to start a rideshare trip.Accordingly, the rideshare server 130 is notified of the driver's inputvia the driver app 402. In some embodiments, the passenger app 408receives a notification of a start of a trip from the rideshare server130. In some embodiments, the driver app 402 sends (step 428) apassenger's pickup location and intended destination of the passenger toa navigation API 440. In turn, the navigation API 440 guides the driverby providing (step 432) turn-by-turn directions to the intendeddestination.

FIG. 5 illustrates a schematic indicating discrete pairwise operationsinvolving a driver's mobile app 502, a passenger's mobile app 528, arideshare server 130, a web portal 134, and a geocoding server 116associated with end of a trip, according to an embodiment of the presentinvention. It is noted that the operations shown in FIG. 5 are notnecessarily performed in a sequence or in an order of any sort. In someembodiments, geocoding server 116 provides (step 506) informationrelating to a driver's current location, intended destination of therideshare trip, a total time traveled, a total distance traveled, tolllocations on the driver's route, etc. to the rideshare server 130. Upondetecting that the driver has arrived at the intended destination, therideshare server 130 informs (step 510) the driver's mobile app that thedriver has arrived at the intended destination. The driver's mobile app502 responds (step 514) to the rideshare server 130 that the ridesharetrip has ended. Accordingly, an invoice reflecting a summary of therideshare trip is sent (step 522) by the rideshare server to thepassenger's mobile device. In some instances, a passenger can optionallyprovide (step 526) a tip amount and a rating/comments for the driver,via the passenger's mobile app 528. In some embodiments, rideshareserver 130 provides (step 518) information relating to the ridesharetrip, e.g., an invoice, a type of vehicle used, a distance traveled, atip amount paid by the passenger to the driver, a rate per unit distanceof travel that is used to calculate the fare, etc. This information can,in some embodiments, be provided to either or both of the driver and thepassenger's account, which can be accessed via web portal 134, e.g., adriver web portal for a driver and a passenger web portal for apassenger.

FIG. 6 illustrates exemplary operations associated with a driver'smobile app associated with authenticating an existing driver's identity,according to an embodiment of the present invention. For example, step602 displays a mobile screen displaying an interface to capture abiometric scan of a driver's right thumb for authentication of adriver's identity. Accordingly, after a driver has provided his or herbiometric scan, the biometric scan provided is compared against adriver's pre-stored biometric scan. In some embodiments, the comparisonis performed at the driver's mobile device. In some embodiments, arideshare server 130 performs the comparison, after receiving thebiometric scan provided by the driver via the mobile app. If thebiometric scan provided (at step 604) by the driver matches with thepre-stored biometric scan, then the driver is allowed to proceed to thenext step of launching the mobile app, e.g., the mobile app goes onlineallowing the driver to use the mobile app. However, if there is amismatch, the driver's mobile app does not allow the driver to proceedfurther, e.g., step 606. FIG. 6 also displays operations associated witha driver's mobile app, after a driver is authenticated successfully. Atstep 608, a driver logs in using login credentials such as a loginid/password on his or her mobile device. The driver's credentials areverified (step 610). If the driver indicates that he or she hasforgotten (step 612) their credentials, then an automated resetcredentials link is sent to the driver by the rideshare server 130 viaemail. If a driver's credentials are successfully verified, then thedriver is allowed (step 616) access to the main screen of the mobileapp. Otherwise, a driver is not allowed (step 618) access. In someembodiments, a driver is provided a unsuccessful verification message,if the driver's credentials are not verified successfully.

FIG. 7 illustrates a flow diagram showing method steps of a process 700by a mobile app for registering a driver on a mobile application runningon a driver's mobile device, according to an embodiment of the presentinvention. Starting at step 702, the process determines whether thedriver chooses to register and provide his or her information via themobile app. In some embodiments, a driver can choose to register via athird party app such as a social media network app, in lieu of, or inaddition to, utilizing the mobile app (associated with the presentlydisclosed system) for entering his or her information. In suchembodiments, the process can receive a driver's information from one ormore respective third parties. In some embodiments, the disclosed systemallows driver referrals in which an existing driver can refer a proposeddriver to the system. Thus, the process determines (for example, basedon information received from rideshare server) whether the registeringdriver has been referred by another driver, at step 706. If the processdetermines that the registering driver has been referred by anotherdriver, then the process jumps to step 722 and continues thereafter.

If, however, the process determines that the registering driver has notbeen referred by another driver, then the process moves to step 708 inwhich the mobile app receives information pertaining to the driver andthe associated vehicle. In some embodiments, the mobile app running onthe driver's mobile device also provides information identifying thedriver's mobile device and the mobile app. For example, the mobile appcan provide a mobile device's International Mobile Equipment Identity(IMEI) number, a mobile app ID, a type and version of the operatingsystem running on the driver's mobile device, the operating system ID ofthe driver's mobile device, etc. At step 710, the process displays amessage on the screen of the driver's mobile device requesting thedriver to provide a biometric scan. After receiving (at step 712) abiometric scan from the driver, the biometric scan is processed (at step714). For example, the mobile app applies image processing methodologiesto determine the edges, boundaries, minutiae of the biometric scan. Insome scenarios, a biometric scan may not be correctly processed, forexample, due to unrecognized artifacts in the biometric scan, or whenthe information in the biometric scan is not sufficient. Thus, theprocess determines (at step 716), if the scan is successful. If the scanis successful, the process moves to step 718 in which informationrelating to the scan is sent to the rideshare server 130. If, however,the scan is not successful, the process lops back to step 710 in whichthe registering driver is requested to provide a biometric scan. Upondetecting a successful scan, the process displays (at step 720) amessage on the screen of the mobile device indicating that registrationwas successful, and the process terminates thereafter.

In some embodiments if the process determines that the registeringdriver has been referred by another driver, then the process enters step734 in which the process requests the registering driver to provide areferral ID. Upon receiving an input from the registering driver, theprocess determines (at step 724) whether the registering driversubmitted a referral ID, or not. In some scenarios, a driver casuallyentering information via the mobile app may inadvertently enter anoption indicating he or she has been referred by another driver, butthen realize later that the option was incorrectly entered. In suchscenarios, the driver may not have a referral ID to provide. Thus, theprocess (at step 724) whether the registering driver submitted areferral ID, or not. At step 726, the mobile app communicates thereferral ID to the rideshare server 130. The server, in turn, sendsverification information to the mobile app verifying (or, denying) thevalidity of the referral ID. This functionality, as can be appreciated,is to prevent a referral ID from being used multiple times or being usedby unrecognized individuals associated with the referral ID, therebypreventing fraud. Based on the received verification information, theprocess determines if the verification for the referral ID wassuccessful, at step 730. If the verification was successful, the processmoves to step 734 in which the referral chain setting in the driver'smobile app is updated. For example, the referral chain setting in thedriver's mobile app can reflect the name of the driver who referred theregistering driver, a number of hierarchical levels included in thereferral chain of the registering driver, etc. If, however, verificationof the referral ID was unsuccessful (at step 730), the mobile appprovides (at step 732) the option to the registering driver to re-enterthe referral ID, and the process loops back to step 722.

FIG. 8 illustrates a flow diagram showing method steps of a process 800by a mobile app running on a driver's mobile device in connection with adriver offering to provide a rideshare trip, according to an embodimentof the present invention. Starting at step 802, the process displays amessage on a driver's mobile device requesting the driver to provide abiometric scan. Thus, in some embodiments, the driver's mobile app staysoffline unless the driver provides his or her biometric scan. Afterreceiving (at step 803) a biometric scan from the driver, the biometricscan is processed (at step 804). For example, the mobile app appliesimage processing methodologies to determine the edges, boundaries,minutiae of the biometric scan. In some scenarios, a biometric scan maynot be correctly processed, for example, due to unrecognized artifactsin the biometric scan, or when the information in the biometric scan isnot sufficient. Thus, the process determines (at step 806), if the scanis successful. If the scan is successful, the process moves to step 808in which information relating to the scan is sent, in some optionalembodiments, to the rideshare server 130. If, however, the scan is notsuccessful, the process lops back to step 802 in which the driver isrequested to provide a biometric scan.

The process receives (at step 810) a response from the rideshare server130, the response including information relating to authentication of adriver's identity. Based on the response, the process determines (atstep 812) whether the authentication was successful. If theauthentication was unsuccessful, the process terminates. If, however,the authentication was successful, the process moves to step 814 inwhich the process receives information pertaining to a passenger'spickup location (e.g., in the form of a latitude longitude or a streetaddress) from the rideshare server 130. In some embodiments, the pickuplocation is displayed on a map. In some instances, information includedin the map is provided by a geocoding server 116 to the rideshare server130 which then conveys the same to the driver's mobile app via theInternet. At step 816, the process displays a message on the screen ofthe driver's mobile device indicating that the authentication wassuccessful. In some embodiments, the message indicating successfulauthentication can be received prior to the process receiving thepassenger's pickup location from the rideshare server 130. After thedriver drives to the passenger's pickup location, in some embodiments,the process waits for a selection from the driver indicating arrival atthe passenger's pickup location. After receiving (at step 818) aselection from the driver indicating arrival at the passenger's pickuplocation, the process displays (at step 820) a message indicating astart of a rideshare trip, assuming the passenger gets in the driver'svehicle. In some embodiments, the process displays route informationrelating to the rideshare trip on a screen of the driver's mobile devicein real-time until the passenger arrives at the passenger's intendeddestination. The route information, for example, can be obtained from ageocoding server 116. Upon arriving at the passenger's intendeddestination, the process displays an indication of the end of therideshare trip and a cost associated with the rideshare trip. In someoptional embodiments, the process enables a driver to enter (at step824) passenger rating information (e.g., on a five star scale, or someother scale) via the mobile app running on the driver's mobile device.The process terminates thereafter. In some embodiments, upon completionof a trip, the mobile app running on the driver's mobile device goesoffline, i.e., breaks network connections with the rideshare server 130.Accordingly, in such embodiments, a driver provides his or her biometricscan via the mobile app, for the mobile app to come back online. In someembodiments, the process of matching or comparison a driver's biometricscan with a pre-stored scan can be performed at the driver's mobiledevice, e.g., by the mobile app running on the driver's mobile device.In such embodiments, the mobile app does not necessarily need to sendthe biometric scan to the rideshare server 130, and accordingly, noresponse from the rideshare server 130 with regard to comparison ofbiometric scans would be necessary, i.e. steps 808 and 810 in the flowdiagram would be optional.

FIG. 9 illustrates a flow diagram showing method steps of a process 900by a mobile app running on a passenger's mobile device in connectionwith a passenger availing a rideshare trip, according to an embodimentof the present invention. Starting at step 902, the process receives apassenger's pickup location (e.g., in the form of an address) from apassenger via the mobile app running on the passenger's mobile device.The process transmits the pickup location to the rideshare server atstep 904. The rideshare server 130 responds back with information aboutthe rideshare driver and the driver's vehicle, which is received by theprocess at step 906. For example, the ride share server 130 can providea name and contact information (e.g., phone number, email, etc.) of thedriver, a photograph of the driver, a make, year, model and photographof the vehicle that the driver is driving. In some instances, therideshare server 130 provides an estimate of the rideshare trip to thepassenger. After the driver drives to the passenger's pickup location,in some embodiments, the process displays (at step 908) a messageindicating a start of a rideshare trip, assuming the passenger gets inthe driver's vehicle. In some embodiments, the process displays routeinformation relating to the rideshare trip on a screen of thepassenger's mobile device in real-time until the passenger arrives atthe passenger's intended destination. The route information, forexample, can be obtained from a geocoding server 116. Upon arriving atthe passenger's intended destination, the process displays (at step 912)end of the rideshare trip and a cost associated with the rideshare trip.In some optional embodiments, the process enables a passenger to enter(at step 914) driver rating information (e.g., on a five star scale, orsome other scale) via the mobile app running on the passenger's mobiledevice. The process terminates thereafter. In some embodiments, a drivercan view, for example by accessing a driver portal or via a mobileapplication, the rating information (e.g., comments/feedback etc.)provided by passengers along with an associated date and time.

FIG. 10 illustrates a flow diagram showing method steps of a process1000 by a rideshare server identifying referral chains, according to anembodiment of the present invention. In this flow diagram, it is assumedthat an existing driver (referrer or “Driver A”) suggests a new driver(referee or “Driver B”) to sign up with the rideshare service. Forexample, a referrer can share a referral ID provided by the rideshareserver 130 with the referee. Starting at step 1002, the process receivesregistration information of driver B during an initial registrationprocess, for example, after launching the driver's mobile app for thefirst time on driver B's mobile device. The registration information caninclude, for example, the driver's biometric scan, the driver's personalinformation, the driver's vehicle information, etc. In some aspects, aregistered driver notifies the rideshare server 130 that he or she hasprovided a referral ID to driver B. Accordingly, when driver B registerswith the rideshare service, driver B may be required to provide thereferral ID provided by the registered driver. Such a methodology canprevent fraud when driver learns B about the rideshare service from aregistered driver, but does not provide the referral ID provided by theregistered driver, in an attempt not to share his or her earnings withthe registered driver.

The process determines (at step 1004) if driver B has indicated, as partof the registration process, as being referred by another driver A. Ifthe process determines that the driver B has indicated as not beingreferred by a driver, then the process terminates. If, however, theprocess determines that the driver B has indicated as being referred byan existing driver, then the process receives a referral ID provided bydriver B. Thus, the process determines (at step 1006) if the referral IDprovided by driver B is a valid referral ID. For example, the processdetermines if the referral ID has been used multiple times, or is beingused by unrecognized individuals associated with the referral ID. If theprocess determines that the referral ID is not valid, then the processterminates. In some embodiments, the process displays a messageindicating that the referral ID provided by driver B is not valid.

If, however, the referral ID is determined to be valid, then the processalso determines (at step 1008) whether an existing driver A has notifiedthe rideshare server 130 of sharing the referral ID with driver B. Ifthe process determines that no existing driver A has notified therideshare server 130 of sharing the referral ID with a driver B, thenthe process terminates, suspecting fraud by registering driver B. If theprocess determines, however, that an existing driver A has notified therideshare server 130 of sharing the referral ID with a driver B, thenthe process updates (at step 1010) a database to reflect thereferrer/referee relationship between driver A and driver B. In someembodiments, the process communicates the referrer/referee relationshipbetween driver A and driver B to either, or both, driver A and driverB's mobile app running on their respective mobile devices. The processterminates thereafter. In some embodiments, a network marketer canprovide referral of proposed new drivers to the rideshare server 130 viathe network marketer portal. A network marketer is an individual or anentity that is not a registered driver of the rideshare service andprovides referral of proposed new drivers to the rideshare server 130. Anetwork marketer can earn percentages of a driver's earnings if such adriver was referred by a network marketer and signed up with therideshare service. In some embodiments, the process of identifyingreferral chains involving network marketers is similar to that in whichan existing driver (referrer or “Driver A”) suggests a new driver(referee or “Driver B”) as discussed in FIG. 10, with Driver A beingreplaced by a network marketer as suitable.

FIG. 11 illustrates several mobile device interface screens 1100 of adriver's mobile app, according to an embodiment of the presentinvention. For example screen 1102 shows options in connection with atleast the following inventive features: referring a proposed new driver(a “Refer” button), viewing a profile of the driver associated with themobile app (a “Profile” button), viewing information about the rideshareservice (an “About Us” button), viewing recent rideshare trips offeredby the driver associated with the mobile app (a “My Recent Trips”button), viewing toll rates at a geographical location (a “Toll Rates”button), viewing a cost of a last rideshare trip offered by the driverassociated with the mobile app (a “Fare Amount” button), facilitating acall with a driver support phone number (a “Call Support” button), andviewing a driver's personal settings on the mobile app (a “Driver'sSettings” button). Screen 1104 shows clickable options for launchingmobile apps of third parties such as social media network and socialtexting apps from the driver's mobile app. Screen 1106 displays anexemplary driver referral chain involving three drivers. For example,screen 1106 shows a driver John referred a driver Jason who referred adriver Tom. Thus, driver John that is associated with the mobile appaccumulates earnings from drivers Jason and Tom.

FIGS. 12-14 illustrate interfaces showing earnings accumulated via adriver's referral chain, according to an embodiment of the presentinvention. According to embodiments of the present disclosure, theinterfaces in FIGS. 12-14 can be viewed by a system administratorassociated with the rideshare service. Region 1202 of FIG. 12 displaysfour exemplary referral chains 1212 (chain 1), 1214 (chain 2), 1216(chain 3), and 1214 (chain 4), each chain showing percentagecontributions of a driver to the rideshare service. Embodiments of thepresent disclosure facilitate a hierarchical earning structure such thatthe rideshare service retains a percentage from each driver in areferral chain. For example, in a referral chain in which driver 1refers driver 2, driver 2 refers driver 3, driver 3 refers driver 4, andso on, the rideshare service retains 15% of driver 1's earnings, 11% ofdriver 2's earnings, 8.5% of driver 3's earnings, 7% of driver 4'searnings, and so on. These percentages are displayed as percentagedeductions in line 1206 of FIG. 12. Lines 1208 and 1210 of FIG. 12respectively display a total amount earned by each driver in a referralchain from offering rideshare services, and an amount retained by therideshare service from each driver's earnings.

Region 1204 of FIG. 12 shows each driver's earnings from their referralchain network. Column 1226 shows percentage earnings by a respectivedriver from other drivers in their referral chain network, e.g., driver1 earns 4% of driver 2's earnings, 2.5% of driver 3's earnings, 1.5% ofdriver 4's earnings, and so on. Column 1228 displays a respectivemonetary amount corresponding to each percentage in column 1228. Column1230 displays a total amount earned by a driver by accumulating his orher earnings from the driver's referral chain. Referral chains 1222 and1224 are exemplary referral chains showing earning by drivers 2 and 3from their respective referral chain networks. FIG. 13 displays adetailed view of an exemplary referral chain showing percentagesretained by the rideshare service and percentage earnings associatedwith each driver in the chain. FIG. 13 demonstrates that the percentagesretained by the rideshare service can be similar as those discussed forchain 1 in FIG. 12. For example, region 1302 in FIG. 13 shows a referralchain in which driver pqr refers driver android, driver android refersdriver nexus, driver nexus refers driver blackberry, and so on, theridesharing service retains 15% of driver pqr's earnings, 11 of driverandroid's earnings, 8.5% of driver nexus' earnings, 7% of driverblackberry's earnings, and so on. In some embodiments, there can betheoretically infinite levels of distribution of earnings. Percentagesassociated with each level can be varied by a system administrator ofthe rideshare server 130. Region 1304 in FIG. 13 shows percentageearnings by a respective driver from other drivers in their referralchain network (e.g., similar to column 1226 in FIG. 12), a respectivemonetary amount corresponding to each percentage (e.g., similar tocolumn 1228 in FIG. 12), and a total amount earned by a driver byaccumulating his or her earnings from the driver's referral chain (e.g.,similar to column 1228 in FIG. 13). FIG. 14 presents a magnified view ofpercentage earnings (region 1402) retained by the rideshare service froma respective driver and other drivers in the subject driver's referralchain network, similar to region 1302 shown in FIG. 13.

FIG. 15 illustrates an interface 1500 displaying a driver's earningshistory, according to an embodiment of the present invention. As shownin FIG. 15, the interface can display columns 1502 (“Passenger ID”),1504 (“Passenger Name”), 1506 (“Date of Rideshare Trip”), 1508 (“EarnedFare”), 1510 (“Tip”), 1512 (“Toll Amount”), and 1514 (“Total PayableAmount”). For example, FIG. 15 shows earnings for a driver pqr frompassengers Akshata (identified by passenger id 16) and John (identifiedby passenger id 20), the dates on which the rideshare trips wereoffered, a cost of the rideshare trip, a tip paid by each passenger todriver pqr, and a toll amount payable to the driver by the rideshareservice in connection with the trip. FIG. 15 also displays a totalpayable amount to driver pqr based on the sum of the cost of the trip,the tip paid by a passenger and the toll amount. According toembodiments of the present disclosure, the interface in FIG. 15 can beviewed by driver pqr or a system administrator associated with therideshare service. In some embodiments, the system provides options toenter a start date and an end date over which a driver's earningshistory is displayed.

FIG. 16 illustrates an interface 1600 showing a passenger's triphistory, as viewed by a system administrator associated with therideshare service, according to an embodiment of the present invention.As shown in FIG. 16, the interface can display columns 1602 (“RequestID”), 1604 (“Owner Name”), 1606 (“Driver”), 1608 (“Date”), 1610(“Time”), 1612 (“Status”), 1614 (“Amount”), and 1618 (“Payment Status”).A request ID column is a unique identifier corresponding to an instanceof a rideshare request from a passenger. A Status column provides astatus of the rideshare trip. A Payment Status column providesinformation pertaining to receiving a payment for a rideshare trip froma passenger's financial institution. There could be multiple paymentstatuses associated with a trip, e.g., completed or request notcompleted depending on whether the payment has been received from apassenger's financial institution or not. In some embodiments, thesystem provides options to enter a start date and an end date over whicha passenger's trip history is displayed.

FIG. 17 illustrates an interface 1700 showing a passenger's pickuplocation with respect to a rideshare driver's location displayed on amap, according to an embodiment of the present invention. For example, arideshare driver's (provider's) location 1702 is relatively near thepassenger's (user's) location 1704. According to embodiments of thepresent disclosure, the interface 1700 can be viewed on the mobile apprunning on the driver's mobile device and/or the mobile app running onthe passenger's mobile device. In some embodiments, a systemadministrator can view/track the driver's movement and/or thepassenger's movement via an interface similar to interface 1700. Thus,according to inventive aspects disclosed herein, the system can obtainin real-time, a number and location of drivers at a geographicallocation who are offering to provide rideshare trips to passengers. Suchaspects are beneficial in selecting, for instance, a driver that islocated closest to a passenger's location such that the driver canarrive at the passenger's pickup location in a short time.

FIGS. 18-19 illustrate interfaces 1800, 1900 linked to a driverdatabase, according to an embodiment of the present invention. As shownin FIG. 18, the interface can display columns 1802 (“Driver ID”), 1804(“Name”), 1806 (“Email”), 1808 (“Phone”), 1810 (“Photo”), 1812 (“Bio”),1814 (“Total Requests”), 1816 (“Status”), and 1818 (“Actions”). Photocolumn provides a link to a driver's photo saved in the database. TotalRequests column indicates a total number of rideshare requests made to adriver by passengers. Status column indicates whether the driver wasapproved based on passing a background check and driving history. Actioncolumn provides a drop-down menu of selectable actions such as decline,set target, edit details, and view details. The decline option removesthe driver from the database. The system administrator can view and editdriver-related information saved in the database, by selecting the editdetails or view details options. The set target option can be used by asystem administrator to set a target amount that a driver is required toearn between a start date and an end date. In some embodiments, a drivercan view the days remaining to reach a target amount. The interfacegenerated upon selecting the set target option is shown in greaterdetail in region 1902 of FIG. 19. In some embodiments, the set targetoption is applicable only to drivers who are part of a referral chain.That is, this functionality, in some embodiments, is disabled fordrivers that are not part of a referral chain.

FIG. 20 illustrates a passenger database, according to an embodiment ofthe present invention. As shown in FIG. 20, the interface can displaycolumns 2002 (“ID”), 2004 (“Name”), 2006 (“Email”), 2008 (“Phone”), 2010(“Address”), 2012 (“State”), 2014 (“Zipcode”), and 2016 (“Actions”).Actions column provides a drop-down menu of selectable actions such asedit passenger details, view history of a passenger's rideshare trips,and view additional passenger-related information saved in database.

FIGS. 21-22 illustrate interfaces 2100A, 2100B, and 2200A, 2200Brespectively showing an embodiment of the network marketer portalpresented by the rideshare server to network marketers. In someembodiments, a network marketer can provide referral of proposed newdrivers to the rideshare server 130 via the network marketer portal. Anetwork marketer is an individual or an entity that is not a registereddriver of the rideshare service and provides referral of proposed newdrivers to the rideshare server 130. A network marketer can earnpercentages of a driver's earnings if such a driver was referred by anetwork marketer and signed up with the rideshare service. When anetwork marketer clicks on a (“View Profile”) button 2102 on theinterface 2100 A, the interface 2100B is displayed. Region 2108 ofinterface 2100A displays a subscription status of a network marketer anda subscription expiration date of a network marketer. In someembodiments, a network marketer has to keep an active subscription withthe rideshare service to be able to refer new drivers and/or earnpercentages of a referred driver's earnings. In some embodiments, adriver that was referred by a network marketer can refer new drivers tothe rideshare service. In such scenarios, a network marketer earnspercentages of all drivers that are included in the subject driver'sreferral chain, in addition to the earnings of the subject driver. A“Referral Tree” button 2103 displays a network marketer's referral tree.Interface 2100B displays a “View Profile” interface to a networkmarketer. For example, region 2104 displays registration informationthat is typically provided by a network marketer when he or she signs upwith the rideshare service. Region 2104 includes example fields such asa first name, a last name, a date of birth, a gender, an email address,a password along with a confirm password, an address including a state,a city and a country. Region 2104 also includes an option for a networkmarketer to add a profile picture. In some embodiments, region 2104includes driver-related fields such as a vehicle number, a type ofvehicle, a license number of the driver, a registration number of thevehicle, an insurance policy number of the vehicle, a license expirationdate of the driver, a registration expiration date of the driver, aninsurance expiration date, etc. However, such driver-related fields canbe deactivated (shown with a “*” in FIG. 21), and accordingly, a networkmarketer would not be able to input data relating to such fields.Additionally, interface 2200B shows a region 2110 for providing anetwork marketer's bank-related information to the rideshare server 130.For example, region 2110 includes a router/routing number of a bank, abank name, a credit card number along with its expiry date and its CVVnumber. In some embodiments, region 2110 includes a referral ID button2112. In some embodiments, when a network marketer clicks on button2112, the rideshare server 130 generates dynamically a referral ID thatcan be shared with a proposed new driver or sent via email to theproposed new driver. In some embodiments, the rideshare server 130retrieves a pre-generated referral ID and presents it to the networkmarketer, in response to the network marketer clicking on button 2112.

FIG. 22 illustrate interfaces 2200A and 2200B showing a portalaccessible by a network marketer for referring a driver to the rideshareservice. Interface 2200A is similar to interface 2100A. For example,interface 2200 displays a network marketer having an ID 12, and a nameJohn Kerry having a subscription expiry date of 21 Jul. 2015, and anumber of drivers (e.g., zero) referred by the network marketer. A“Subscription Status” button 2210 when clicked on this interface revealswhether the network marketer's subscription is expired or stillsubscribed, indicated in box 2208. Interface 2200B also includes aStatus button 2214, which when clicked, reveals the names of the driversthat were referred by the network marketer. In some embodiments,existing drivers cannot be referred by a network marketer to therideshare service. In some embodiments, an existing network marketer canrefer another driver by clicking on a Refer Driver button 2206. In someembodiments, an existing network marketer can refer another networkmarketer by clicking on a Refer Network Marketer button 2204. New driverreferrals and new network marketer referrals can be made by social medianetworks or via email, e.g., as shown in box 2212. For example, if a newdriver is referred, then a downloadable link to a driver's mobileapplication is shared, inviting the new driver to sign up with therideshare service. If a new network marketer is being referred, then alink to the network marketer portal (for signup) is shared.

The terminology used in the description presented below is intended tobe interpreted in its broadest reasonable manner, even though it isbeing used in conjunction with a detailed description of certainspecific examples of the technology. Certain terms may even beemphasized below, however, any terminology intended to be interpreted inany restricted manner will be overtly and specifically defined as suchin this Detailed Description section.

In this disclosure, numerous specific details have been set forth inorder to provide a thorough understanding of embodiments of the presentdisclosure. It will be apparent, however, to one skilled in the art thatembodiments of the present disclosure may be practiced without some ofthese specific details.

Embodiments of the present disclosure include various steps. The stepsmay be performed by hardware components or may be embodied inmachine-executable instructions, which may be used to cause ageneral-purpose or special-purpose processor programmed with theinstructions to perform the steps. Alternatively, the steps may beperformed by a combination of hardware, software and/or firmware. Aswill be understood, the steps of the processes shown in FIGS. 7-10 arenot necessarily completed in the order shown, and various steps mayoperate concurrently and continuously. It will be understood that thedrawings and discussions herein refer to two items of digital content,i.e. a first item and a second item. But such drawings and discussionsare for exemplary purposes only. In alternate embodiments, multiple(e.g., more than two) items of digital content can be used as a part ofa validation process.

Embodiments of the present disclosure may be provided as a computerprogram product, which may include a machine-readable medium havingstored thereon instructions, which may be used to program a computer (orother electronic devices) to perform a process. The machine-readablemedium may include, but is not limited to, floppy diskettes, opticaldisks, compact disc read-only memories (CD-ROMs), and magneto-opticaldisks, ROMs, random access memories (RAMs), erasable programmableread-only memories (EPROMs), electrically erasable programmableread-only memories (EEPROMs), field programmable gate arrays (FPGAs),application-specific integrated circuits (ASICs), vehicle identitymodules (VIMs), magnetic or optical cards, flash memory, or other typeof media/machine-readable medium suitable for storing electronicinstructions.

Moreover, embodiments of the present disclosure may also be downloadedas a computer program product or data to be used by a computer programproduct, wherein the program, data, and/or instructions may betransferred from a remote computer to a requesting computer by way ofdata signals embodied in a carrier wave or other propagation medium viaa communication link (e.g., a modem or network connection).

1. A method for facilitating vehicle rideshares to passengers by driversvia drivers' mobile devices, the method comprising: receivingregistration information of a driver, wherein the registrationinformation includes a first biometric scan of the driver; in responseto detecting an indication that the driver elects to provide a ridesharetrip requested by a passenger, transmitting a request to provide asecond biometric scan of the driver; upon receiving the second biometricscan of the driver, comparing the first biometric scan and the secondbiometric scan for a match; and in response to detecting the match,transmitting pickup information, wherein the pickup information includesa name of the passenger and a pickup location of the passenger.
 2. Themethod of claim 1, wherein the biometric scan is received via abiometric sensor coupled to, or inside a mobile device.
 3. The method ofclaim 1, wherein the registration information includes a name of thedriver and at least one of license information of the driver, a socialsecurity number of the driver, car information, a picture of the driver,and a picture of the car.
 4. The method of claim 1, further comprising:receiving referral information for the driver, wherein the referralinformation includes a referral code provided to the driver by anexisting driver associated with the ridesharing server; verifying thereferral information; and in response to a successful verification ofthe referral information, transmitting information for displaying a linkconnection between a user profile of the driver and a user profile ofthe existing driver on a user interface of a mobile device.
 5. Themethod of claim 1, further comprising: transmitting an intendeddestination of the passenger; and transmitting, in real-time, navigationdirections to the intended destination along a route from the pickuplocation to the intended destination.
 6. The method of claim 5, whereina source of the navigation directions is a geocoding server.
 7. A methodfor facilitating rideshares to passengers by drivers via a ridesharingserver, the method comprising: receiving, at the ridesharing server,registration information via a mobile application running on a mobiledevice of a potential driver that is signing up with the ridesharingserver for providing rideshare trips, the registration informationincluding a first biometric scan of the driver; in response todetermining that the driver selects to offer a rideshare trip, receivinga second biometric scan from the driver; comparing the first biometricscan and the second biometric scan for a match; and in response todetecting the match, providing pickup information to the mobileapplication running on the mobile device of the driver, wherein thepickup information includes a name of a passenger and a pickup locationof the passenger.
 8. The method of claim 7, wherein the registrationinformation includes a name of the driver, license information of thedriver, a social security number of the driver, car information, apicture of the driver, and a picture of the car.
 9. The method of claim7, further comprising: receiving referral information from the mobileapplication running on the mobile device of the driver, wherein thereferral information includes a referral code provided to the driver byan existing driver associated with the ridesharing server; and inresponse to receiving information corresponding to successfulverification of the referral information, creating a link connection ina database storing a userprofile of the driver and a userprofile of theexisting driver.
 10. The method of claim 7, further comprising:receiving referral information from the mobile application running onthe mobile device of the driver, wherein the referral informationincludes a referral code provided to the driver by an existing driverassociated with the ridesharing server; in response to receivinginformation corresponding to successful verification of the referralinformation, creating a hierarchical link in a database storing auserprofile of the driver and a userprofile of the existing driver; andtransmitting to the mobile application running on the mobile device ofthe driver, information pertaining to signup of the driver with theridesharing service.
 11. The method of claim 10, further comprising:transmitting to a mobile application running on a mobile device of theexisting driver, information pertaining to signup of the driver with theridesharing service.
 12. The method of claim 10, wherein thehierarchical link includes one or more levels, each level correspondingto a referral link between a first driver that has signed up with theridesharing server and a second driver that refers the first driver. 13.The method of claim 10, wherein the hierarchical link includes one ormore levels, each level corresponding to a referral link between a firstdriver that has signed up with the ridesharing server and a seconddriver that refers the first driver, further comprising: providing apercentage of earnings of the driver to the existing driver according toa level in the hierarchical link connection. 14.-20. (canceled)
 21. Themethod of claim 1, wherein the first biometric scan is stored for laterretrieval.
 22. The method of claim 7, wherein the first biometric scanis stored for later retrieval.
 23. A non-transitory machine-readablestorage medium comprising instructions that, when executed by aprocessing device, cause the processing device to: receive an indicationthat a driver elects to provide a rideshare trip requested by apassenger; retrieve pre-stored registration information for the driverthat includes a first biometric scan of the driver; transmit a requestto provide a second biometric scan of the driver in response toreceiving the indication to provide the rideshare trip; compare thefirst biometric scan and the second biometric scan upon receiving thesecond biometric scan to determine if there is a match; and transmitpickup information in response to a determination that that there is amatch, wherein the pickup information includes a name of the passengerand a pickup location of the passenger.